-8- 



GUPTA et al. 
Appl. No. 09/893,742 
Atty. Docket: 2013.0010000 



Remarks 

Reconsideration of this Application is respectfully requested. 

Upon entry of the foregoing amendment, claims 1-22 are pending in the 
application, with claims 1, 7, 9, 15, and 16 as being the independent claims. No claims 
are sought to be cancelled. No new claims are sought to be added. These new claims 
introduce no new matter, and their entry is respectfully requested. 

Based on the above amendment and the following remarks, Applicants 
respectfully request that the Examiner reconsider all outstanding rejections and that they 
be withdrawn. 

Rejections under 35 US.C. § 102 

Claims 1-17 have been rejected under 35 U.S.C. § 102(e) as being anticipated by 
Published U.S. Patent Application No: 2001/0054074, entitled Electronic Mail System 
and Device, filed by Kiyoko Hayashi on March 8, 2001 ("Hayashi Patent Application"). 
Applicants respectfully traverse this rejection. Based on the remarks set forth below, 
Applicants respectfully request that this rejection be reconsidered and withdrawn. 

On Nov. 1, 2005, Applicants submitted a 37 C.F.R. 1.131 Declaration that 
demonstrated a reduction to practice of the present invention prior to March 8, 2001 . As 
a result, the Hayashi Patent Application does not quality as a valid reference to serve as a 
basis to reject the claims of the present invention. 

In the present office action, the Examiner has indicated that evidence submitted 
by Applicants in a 37 C.F.R. §1.131 Declaration was insufficient to establish a reduction 
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to practice prior to the effective date of the Hayashi Patent Application. Specifically, the 
Examiner stated: 

(1) The evidence does not indicate whether it is an actual reduction to practice or 
a constructive reduction to practice. 

In response to point (1), Applicants confirm that an actual reduction to practice of 
the invention prior to March 8, 2001 did occur. Applicants respectfully note that the 
Declaration of Virad Gupta, Shital Mehta and David Israel under 37 C.F.R. § 1.131 
("Declaration") does demonstrate that an actual reduction to practice the invention prior 
to March 8, 2001 occurred. Specifically, the Declaration notes that the "software used to 
implement the invention was checked into the repository before March 8, 2001." 
Declaration at 1 . The Declaration also notes that "the invention was reduced to practice 
prior to the earliest filing date" of the Hayashi Patent Application. Id. 

The Examiner also stated: 

(2) The evidence does not provide sufficient evidence showing any of the 
following: 

(a) >(actual)< reduction to practice of the invention prior to the effective date 
of the reference; or 

(b) conception of the invention prior to the effective date of the reference 
coupled with due diligence from prior to the reference date to a subsequent (actual) 
reduction to practice; or 

(c) conception of the invention prior to the effective date of the reference 
coupled with due diligence from prior to the reference date to the filing date of the 
application (constructive reduction of practice). 
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(3) The evidence does not provide sufficient evidence showing the claimed 
invention as set forth in the application. 

In response to points 2 and 3, Applicants respectfully observe that the Declaration 
included two exhibits that provide sufficient evidence to demonstrate that actual 
reduction to practice occurred prior to March 8, 2001. Exhibit A included a redacted 
excerpt of a document repository that showed the dates for the design document 
corresponding to the present invention. Exhibit B included a redacted excerpt of a 
source code repository that showed the dates for the source code used to implement the 
present invention, which corresponded to the design document highlighted in Exhibit A. 

Applicants herein submit the proxyserversDD.doc that was referenced in Exhibit 
A to further demonstrate an actual reduction to practice of the present invention prior to 
March 8, 2001 . The proxyserversDD.doc represents the design document upon which 
the source code, referenced in Exhibit B, was developed. Section 1 .1 of the 
proxyserversDD.doc discloses independent claim 1. Specifically, Section 1.1 notes that 
email messages will be stored on an email server and that voice and fax messages will be 
stored on a separate storage system referred to as Harmony. This discloses the second 
element of claim 1 of storing on a mass storage device a media component. Section 1.1 
notes that there will be an email on the email server for each voice/fax message 
containing proprietary header which contains a pointer to the voice/fax message on the 
storage device, referred to as NAS. This discloses the third element of claim 1 of storing 
on an email server said non-media component of said message a corresponding reference 
to said stored media component of said message. The first element of claim 1 of 
receiving a message with a media and non-media component can be inferred from 
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Section 1.1. The proxyserversDD.doc similarly discloses the elements of independent 

claims 7, 15, and 16. 

Applicants submit that they have provided a clear explanation of the exhibits that 

point out exactly what facts are established and relied upon by Applicants to demonstrate 

an actual reduction to practice prior to March 8, 2001. Having demonstrated a date of 

invention prior to March 8, 2001, Applicants respectfully submit that the Hayashi Patent 

Application does not qualify as a valid reference. Therefore, Applicants respectfully 

submit that claims 1-17 are patentable over the Hayashi Patent Application. 

Reconsideration and withdrawal of the rejections of claims 1-17 is respectfully 

requested. 

Claims 18-22 have been rejected under 35 U.S.C. § 103 as being unpatentable 
over the Hayashi Patent Application in view of U.S. Patent Application No. 
2001/0047289. ("Prahlad Patent Application"). Applicants respectfully traverse this 
rejection. Based on the remarks set forth below, Applicants respectfully request that this 
rejection be reconsidered and withdrawn. 

As explained above, the Hayashi Patent Application is not a valid reference upon 
which a rejection can be based. The Examiner alleges that the Prahlad Patent 
Application only discloses a storage device and email device being physically separated. 
Therefore, claims 18-22 are patentable over the combination of the Hayashi Patent 
Application and the Prahlad Patent Application. 

Notwithstanding the above showing that the Hayashi Patent Application does 
not qualify as a valid reference, Applicants respectfully disagree with the Examiner's 
conclusion that arguments presented in the Applicants 1 previous responses to Office 
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Actions did not overcome the Examiner's rejections based on the Hayashi Patent 

Application. Even if the Hayashi Patent Application was a valid reference, Applicants 

do not acquiesce to the Examiner's allegations that the claims of the present invention 

would be anticipated or obvious in light of the Hayashi Patent Application. 
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Conclusion 



All of the stated grounds of objection and rejection have been properly traversed, 
accommodated, or rendered moot. Applicants therefore respectfully request that the 
Examiner reconsider all presently outstanding rejections and that they be withdrawn. 
Applicants believe that a full and complete reply has been made to the outstanding 
Office Action and, as such, the present application is in condition for allowance. If the 
Examiner believes, for any reason, that personal communication will expedite 
prosecution of this application, the Examiner is invited to telephone the undersigned at 
the number provided. 

Prompt and favorable consideration of this Amendment and Reply is respectfully 
requested. 



Respectfully submitted, 




Michael D. Specht 
Attorney for Applicants 
Registration No. 54,463 




1 100 New York Avenue, N.W. 
Washington, D.C. 20005-3934 
(202)371-2600 
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Proxy Servers Design Document 



1 Scope: 

Proxy servers will help in following: 

1. Single message store 

2. Message deletion 

3. Quota management 

1 .1 Single Message Store 

We want to maintain a single message store with all email messages being stored on the email server and 
all voice and fax messages being stored on Harmony(current storage solution being NAS). There will be an 
email on the email server for each voice/fax message containing the proprietary header which contains a 
pointer to the voice/fax message on NAS. When the user is accessing his mails from the phone, voice-mail 
application will look at the proprietary header for the pointer to the voice/fax file and play the actual file 
from the NAS. But if email clients access the mail server directly then all they will get is a email header 
without any voice content. 

To solve this problem we need IMAP and POP proxy servers which sit between email server and the email 
clients and whenever an IMAP or POP client asks for these special email messages, these proxy servers 
will actually attach the voice/fax file with these special email messages. This will ensure that email clients 
get these voice and fax attachments along with their email. 



1.2 Message Deletion 

IMAP proxy server will catch "EXPUNGE" and "CLOSE" commands and will fetch the proprietary 
message header(X-IPMsglD) for all the messages which were marked "DELETED". After getting these 
proprietary headers, the proxy will actually issue the requested command from the client ("EXPUNGE" or 
"CLOSE"). These proprietary header information will be sent to message deletion task for further 
processing. 



1.3 Message Quota 

The functionality is exactly the same as above. Only addition being that proxy servers will also have to get 
message size from the proprietary header X-IPMsgSize and send it to the message deletion task. 
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Diagram 1: Proxy servers 

Note: Voice-mail state machine will directly talk to Mail server and will not go through IMAP proxy. This 
is because it does not need to retrieve voice/fax attachments when getting messages from the email server. 



2 Design Overview 



2.1 IMAP proxy server 

Proxy server will receive IMAP requests from the client. These requests will be passed to the IMAP4 
server provisioned in the proxy. In turn the response received from the server will be passed back to the 
client. These will be true for most of the IMAP4 requests received. Some of the IMAP4 request and 
responses will undergo special processing to support the features such as single message store, message 
deletion and quota management. These IMAP4 requests and their responses which require special 
processing are described in brief here. 



2.1.1 All FETCH requests and responses 

FETCH requests will be of the form: 

FETCH <message set> <message data item names> or 

UID FETCH <message set> <message data item names> 

The current design does not take into account the FETCH of independent message parts. The proxy server 
will support the attachment of voice files only if the whole message body is requested. So whenever there is 
a FETCH request for the full message body, the proxy will parse the response coming from the mail server. 
It will decide whether a message is voice/fax depending on the presence of the proprietary message header 
"X-IPMsgID". So when the server responds with dummy attachments for these voice/fax messages, the 
proxy will replace them with the actual voice/fax files which will be determined based on "X-IPMsgID" 
header. 



Note: 

1 . X-IPMsgID should be present in the top most message of the mime structure. A message which does 
not have this proprietary header in the top most messages but has it somewhere in its body parts will 
not be treated as a voice/fax message but only as an ordinary email. This will happen when a voice 
messages is being replied to or forwarded by an email client. As soon as a voice/fax message is replied 
by or forwarded by an email client it will cease to be a voice/fax message and will be ordinary email 
only. 

2. X-IPMsgID will have multiple message ids. This header will contain all the message ids for the voice 
messages in the current message and its extensions. The last message id will be the id for the voice/fax 
part of the current message. 

2.1.2 "EXPUNGE" and "CLOSE" requests 

The proxy server will trap all "EXPUNGE" and "CLOSE" requests to provide message deletion 
information to the application server. 

Currently we are supporting only "INBOX", so the proxy server will trap these messages only for the 
"INBOX" folder. 

After trapping these commands, the proxy server will issue commands to the Mail server to find out how 
many voice/fax messages will get deleted and fetch proprietary headers for all of them. 

Client to proxy : EXPUNGE/CLOSE 

Proxy to server : uid search deleted header X-IPMsgID "" 

Server to proxy : search 29 30 

Proxy to server : uid fetch 29,30 body. peek[header. fields (X-IPMsgID X-IPMsgSize)] 

Server to proxy : * 5 FETCH (UID 29 BODY[HEADER.FIELDS X-IPMsgED X-IPMsgSize)} {48} 

X-IPMsgID: 972456789801 972456789823 

X-IPMsgSize:3120 

) 

* 6 FETCH (UID 30 BODY[HEADER.FIELDS X-IPMsgID X-IPMsgSize)] {48} 

X-IPMsgID: 972456789810 

X-IPMsgSize:3120 

) 

Proxy to server: EXPUNGE/CLOSE 



Then proxy server will forward all these information about the messages deleted to the Application server. 



2.1.3 Add message waiting mechanism 



